Cache target/ folders in CI
#2376
Conversation
TODO: Explain why this is a good idea: * We will definitely need this for speeding up CI, which is the real impetus here. * This basically shouldn't affect anybody that is using a library version of Naga; only binaries consumers, who still have a choice whether they will honor a `Cargo.lock`.
|
Curious: how does this compare to the rust-cache action from matklad? |
|
@cwfitzgerald: I don't know what you're referring to. Got a link? |
|
Ah sorry, gave you the wrong source :) https://github.com/Swatinem/rust-cache |
|
@cwfitzgerald: In fact, that is the tool being used in this PR. 😉 |
|
Hello, thank you for your PR against Naga! As part of gfx-rs/wgpu#4231, we have moved development of Naga into the wgpu repository in the Naga subfolder. We have transferred all issues, but we are unable to automatically transfer PRs. As such, please recreate your PR against the wgpu repository. We apologize for the inconvenience this causes, but will make contributing to both projects more streamlined going forward. We are leaving PRs open, but once they are transferred, please close the original Naga PR. |
TODO: Explain why this is a good idea:
impetus here.
version of Naga; only binaries consumers, who still have a choice
whether they will honor a
Cargo.lock.Current stats on savings:
ci.yml:check-msrvci.yml:test:Default testci.yml:test:Test all featuresci.yml:check:Check benchmarksci.yml:check:Check naga-fuzzci.yml:documentationvalidate-linux.yml:validate-linux